The present invention relates to a network virtualization technology and more specifically to a Virtual eXtensible LAN (VXLAN) intercommunication mechanism for multicast (M-VIM) in cloud networking.
An overlay network is created on top of an existing network by generating logical communication links between hosts within the service domain. The communication links are commonly implemented by tunneling, where a delivery network protocol encapsulates a payload protocol.
VXLAN is a network virtualization technology widely used in Data Center Networking (DCN) that attempts to improve the scalability problems associated with large cloud computing deployments. It uses a virtual LAN (VLAN)-like encapsulation technique such as MAC Address-in-User Datagram Protocol (MAC-in-UDP) to encapsulate MAC-based OSI layer 2 Ethernet frames within layer 4 UDP packets.
VXLAN makes it possible for the Virtual Machine (VM)'s transparent transfer between hosts, and even data centers. VXLAN solves the problem of inadequate Table Sizes at Top of Rack (ToR) Switches, and breaks the limit of 4096 VLAN id's (the “4K limit”) in the traditional VLAN, as well as the low link utilization efficiency induced by the classical Spanning Tree.
But, under the VXLAN standard, there are still some variants for which Control Planes (CP) are implemented in a different way, but use the same encapsulation format as VXLAN, such as IBM Software Defined Network-Virtual Environment (SDN-VE). The encapsulation format is based on a Centralized Network Virtualization Overlay (NVO3) Implementation (CNI), which uses a centralized policy server to support a tunnel resolution instead of relying on a multicast query scheme which is now the core tunnel resolution mechanism of VXLAN. VXLAN related NVO3 implementations are referred to as Centralized NVO3 Implementation (CNI) due to their centralized control plane.
VXLAN and Centralized NVO3 implementation (CNI) have compatible data frame formats. Both of VXLAN and CNI provide an overlay solution for expanding a layer 2 network over a layer 3 network. The overlay solution is comprised of a stateless tunneling protocol, where layer 2 frames are wrapped within layer 3 packets, after adding a VXLAN header containing a 24-bit VXLAN Network Identifier (VNID). A VNID identifies an overlay network segment, thus expanding the number of unique virtual segment to 16M. An endpoint of a virtual segment is called a Virtual Tunnel Endpoint (VTEP), and is located within the hypervisor on the hosting server, thus the VXLAN header is known only to VTEPs, and the VTEP performs the encapsulation/de-capsulation work when it receives data traffic from the overlay port or underlay port.
However, there are many differences in multicast traffic forwarding behavior between VXLAN and CNI domains.
VXLAN has no dedicated control plane, that is, there is no out-of-band mechanism that could be used for VMs to register their tunnel information. A VXLAN VNID is mapped to an underlay multicast address.
Conventionally, in VXLAN, a Host1 spawns a VM with MAC1 in VNID 5001. Then Host1 will send an Internet Group Management Protocol (IGMP) join packet for underlay multicast group 239.1.1.100. VM with MAC2 and Host4 do the same thing after the VM spawn.
The VM with MAC1 starts sending broadcast/multicast to its destination. Host1 encapsulates this packet with a VXLAN header, and with a destination, which is 239.1.1.100. Then, any host with VNID 5001 could receive this broadcast/multicast traffic.
In the CNI domain, data traffic is handled by distributed data plane entities called the Network Virtualization Edges (NVE), while control is achieved through a control plane engine called Network Virtualization Authority (NVA). The NVE entities are in charge of connectivity and policy enforcement in a CNI environment, and get the respective control information from NVA (if not available in local cache). Typically, an NVE is located on a physical server, and serves the Virtual Machines (VM) hosted by this server. All traffic sent and received by a VM must traverse its hosting NVE. The NVA maintains the logical view of the network. This mechanism is for all kinds of traffic: unicast, multicast and broadcast.
For multicast in the CNI domain, the receiver VM sends an IGMP join packet. When the NVE receive this IGMP join, it will register a receiver to NVA with the following information: multicast address, VNID and host tunnel endpoint IP.
When the NVE receives a multicast sent by a source VM, the NVE will check with the NVA for the destination address and VNID and the NVA will respond with the necessary tunnel information which contains all the target NVEs for the multicast address. Then, the NVE carrying source VM will encapsulate the original multicast with a CNI header in which the destination address is a destination host tunnel IP. This mechanism allows overlay networks to transmit multicast traffic over an underlay network which doesn't support multicast traffic forwarding.
When a VM hosting in a VXLAN domain wants to communicate with a VM hosting in a CNI domain for multicast, it will not be achieved because of the different address resolve mechanisms in the control plane between VXLAN and CNI, however both VXLAN and CNI use the VXLAN frame encapsulation for tunneling. Currently, there is no solution to resolve this issue.